Cameras are usually used in monitoring systems, such as anti-theft monitoring systems and home security electronic eye systems. A camera used in a conventional monitoring system usually includes a base, a camera and a power system mounted thereon. The power system is directly connected to a control console through a data line. The control console controls the power system with dedicated signaling, and thereby controls the movement of the camera and the assistant equipment.
The conventional technical scheme for controlling the movement of the camera and the assistant equipment causes the following technical problems: 1. The camera control method is professional, thus requires heavy investment; 2. Though streaming media techniques are widely used today, the camera control method is not compatible with popular streaming media systems because it employs dedicated signaling control; 3. The camera may only be controlled by the control console; as a result, the user has to operate in front of the control console, which is inconvenient.
In addition, the existing camera control technique is on individual user basis, and thus the user is not required to input the user name and password. However, cameras are a rare resource, and reuse of the camera resource is not supported in the existing technique.
Reuse of resources is very popular today, for example, for streaming media network resources, the user management method of which employs an authentication process to enable different users to access the resources. Specifically, different access rights are set for different user levels, such as low-level, middle-level, and high-level access rights. Suppose a high-level user attempts to access the system when a middle-level user is using the system, the system will judge the access rights of these users; if the system finds a lower-level user is occupying the system resources and a higher-level user requests to access the system resources, the system will release the resources occupied by the lower-level user automatically and provide the resources to the higher-level user.
FIG. 1 shows a time sequence diagram of authentication for streaming media in the prior art. The existing streaming media resource authentication technique is to deploy a Hypertext Transfer Protocol (HTTP) server between the clients and the streaming media server, and make comparison of user name and password in HTTP, so as to identify a user. And, on that basis, the Uniform Resource Identifier (URI) of the requested streaming media resource is sent to the streaming media playback platform, which will send a playback request on the basis of the URI. The streaming media platform will judge validity of the URI, and provide the corresponding media content to the requester. The requester will receive the issued media content and play back the media content. The process is as follows:
Step 101: The client initiates a logon request in HTTP to the HTTP server, with the user name and the password carried in the request message; in this example, the user name is Alice, and the password is 12345.
Step 102: The HTTP server authenticates the request from the client, and, if the authentication is successful, returns an HTTP 200 OK response message to the client.
Step 103: The client accomplishes the user logon process. Next, for the streaming media content of interest, if the client wants to play the content, it will send an HTTP GET request to the HTTP server, to obtain the URI of the streaming media content that is required to play back the streaming media content in Real-Time Streaming Protocol (RTSP). In this example, a request for the URI is initiated by means of an HTTP GET request.
Step 104: Because the HTTP server is only a Portal for the streaming media server, it does not store any media information or the URI of the corresponding streaming media content. Upon receiving the HTTP GET request, the HTTP server sends the HTTP GET request for the URI of the streaming media content to the streaming media server.
Step 105: When receiving the HTTP GET request from the HTTP server, the streaming media server generates a URI address for the streaming media player in accordance with the address of the streaming media content requested in the HTTP GET request, and sends the URI in an HTTP 200 OK response message to the HTTP server in RTSP protocol. In addition, the streaming media server records generation time of the URI, and set a validity period for the URI locally. When the streaming media client requests for the streaming media content by means of the URI address, the request is valid only in the validity period, and invalid when the validity period expires.
Step 106: The HTTP server returns the URI address of the streaming media content obtained from the streaming media server in the HTTP 200 OK response to the client that requests for the URI address.
Step 107: The obtained URI address of the streaming media content is used by the client for initiating a streaming media obtaining request in RTSP protocol. In this example, an RTSP PLAY command is used for playing back the streaming media content specified by the URI. The RTSP message is not forwarded by the HTTP server; instead, the obtained URI can be directly manipulated in RTSP protocol.
Step 108: The streaming media server authenticates validity and time limitation of the requested URI address after receiving the RTSP PLAY request from the client, and, if the authentication is successful, returns an RTSP 200 OK response message to the client that initiates the request.
Step 109: The streaming media server transmits the media streaming containing the streaming media content in RTP/RTCP protocol to the client. The client watches the requested media content normally.
Step 110: After the media content has been watched by the client, the client initiates a link teardown process. The process is accomplished with an RTSP TEARDOWN command.
Step 111: When receiving an RTSP TEARDOWN command, the streaming media server disconnects the transmitting media streaming. After that, it returns an RTSP 200 OK response message to the user, to notify the user of the successful result. In this example, the 200 OK response is ignored.
Step 112: After a period, i.e., when the original URI requested by the client expires, the client initiates a streaming media content playback request to the streaming media server by utilizing the original URI address according to the original process.
Step 113: When receiving such a request, the streaming media server judges validity of the URI; if the streaming media server finds the URI has expired, it returns a failure request.
Step 114: After the client modifies the URI address in the RTSP request, it sends a streaming media content playback request again.
Step 115: The streaming media server authenticates the received URI address again; if the streaming media server finds the URI is invalid, it returns a failure request.
Alternatively, the identity authentication and streaming media on demand functions can be implemented as shown in FIG. 2. In FIG. 2, the steps 201, 202, and 206-215 are identical to the steps 101, 102, and 106-116 shown in FIG. 1, and therefore will not be described further here; the steps 203-205 are different from the steps 103-105 shown in FIG. 1, and are as follows:
Step 203: After the user logs on the HTTP server, the HTTP server requests for a set of URI addresses that may be used by the user from the streaming media server. The request is initiated by means of an HTTP GET request.
Step 204: The streaming media server returns the URI information of streaming media for a certain user to the HTTP server in HTTP protocol, from the URIs requested by the HTTP server. The HTTP server buffers the URI for the user for later use.
Step 205: The user chooses the streaming media content to be played and requests for the URI of the media content from the HTTP server in HTTP protocol.
It can be seen from above that the conventional resource authentication scheme has the following technical problems: 1. It is inconvenient for implementing access right control for streaming media contents or reuse of resources; 2. All of the control has to be accomplished through a third-party HTTP server, and therefore the cost is very high.